Use of configurations in device with multiple configurations

ABSTRACT

The invention relates to a method for arranging use of configurations in a device with multiple configuration data sets manageable by one or more external managing entities. The device comprises access control information originated and/or controlled by an external managing entity for defining a right to access a configuration data set. The access control information is checked in response to an indication from an application requiring access to a configuration data set. If the application is, on the basis of the access control information, entitled to access the configuration data set, access to the configuration data set is arranged for the application.

FIELD OF THE INVENTION

The invention relates to arranging use of configurations in devices withmultiple configurations, more specifically to arranging access controlinto configuration data sets manageable by one or more externalmanagement devices.

BACKGROUND OF THE INVENTION

As different data processing devices, such as mobile stations, becomemore complex, the significance of device management becomes morepronounced. Devices require several different settings, such as settingsrelated to Internet access points, and it is arduous and difficult for auser to set them manually. To solve this problem, device managementsolutions have been developed so that the administrator of a company'sinformation system or a teleoperator can set an appropriateconfiguration in the device. Device management generally refers toactions by which a person not using the device can change theconfiguration of the device; for instance change the settings or even aprotocol used by the device. In addition to device-specific settings, itis also possible to transmit user-specific data, such as user profiles,logos, ringing tones, and menus with which the user can personallymodify the settings of the device, or the modification takes placeautomatically in connection with device management.

One of the device management standards is OMA (Open Mobile Alliance) DM(Device management), which is partly based on the SyncML(Synchronization Markup Language) protocol. For instance, a personalcomputer (PC) may act as a device management server in a devicemanagement protocol, and a mobile station as a device management client.The items managed in the device management client are arranged asmanagement objects. The management objects are entities that can bemanaged by server management commands in the device management client.The management object can for instance be a number or a large entity,such as a background image or a screensaver. In OMA device management,the management objects are arranged in a management tree.

Some typical manageable items comprise operator specific connectionsettings, for instance GPRS (General Packet Radio Service) connectionsettings. By OMA DM procedures, these operator specific sets ofsettings, which may also be referred to as configurations, in a userterminal device can be maintained by an operator controlled managementserver. For instance, WAP (Wireless Application Protocol) settings forusing WAP services of a service provider may be provisioned as aconfiguration context for the terminal device.

Some managed items may comprise user specific and controlledinformation, such as screen savers and ringing tones. Further, thedevice may be used for accessing a corporate information system, forinstance a file system, intranet pages and an e-mail system therein. Forthis purpose the device needs to comprise one or more configurations forarranging access to these corporate information system services. Forsecurity purposes it is desirable for corporate IT personnel to be ableto control these settings. Therefore, a device may comprise multipleconfigurations from different managing parties and it should be possibleto enable access to a specific configuration only for an authorizedmanagement party. In accordance with the OMA DM protocol, specified inOMA specification “SyncML Device Management Protocol”, version 1.1.2, 12Dec. 2003, 41 pages, in the set-up phase of a management session, amanagement server is authenticated on the basis of credentials receivedfrom the management server. Further, as illustrated in OMA specification“SyncML Management Tree and Description”, version 1.1.2, 2 Dec. 2003, 44pages, a node of a management tree may be specified by an access controllist (ACL) comprising a list of identifiers and access rights associatedwith each identifier. As described in Chapter 7.7.1, the access rightsgranted by ACL define management server identifiers authorized to get,add, replace, and/or remove a node. Thus, different access rights may begiven to various device management servers, and device managementcommands from non-entitled management servers are not performed on themanagement tree. However, besides a capability to control access ofmanagement servers to nodes of a management tree, a general need furtherexists to limit the use of the configurations in the device. Forinstance, companies wish to control terminals used for accessing companyIT services in a better way in order to protect corporate data andservices.

BRIEF DESCRIPTION OF THE INVENTION

A method, a device management system, data processing devices, and acomputer program product are now provided, which are characterized bywhat is stated in the independent claims. Some embodiments of theinvention are described in the dependent claims.

According to an aspect of the invention, a device with multipleconfiguration data sets comprises access control information originatedand/or controlled by an external managing entity for defining a right ofan application to access a configuration data set. The access controlinformation is checked in response to an indication from an applicationrequiring access to a configuration data set. If the application is, onthe basis of the access control information, entitled to access theconfiguration data set, access to the configuration data set is arrangedfor the application.

The term “configuration data set” generally refers to a set of datacomprising configuration information having direct or indirect effect onone or more functions of the device or an application in the device. Forinstance, the configuration data set may comprise an IP address or adomain name of a server on the basis of which a connection is arrangedfrom the device.

The invention makes it possible to control access of applications toconfiguration data. More particularly, access rights may be specifiedand/or controlled by an external entity. A device may comprise multipleconfiguration data sets with different access control properties. Forinstance, a configuration data set specifying access settings for acorporate information system may be controlled by configurationmanagement software operated by corporate IT personnel.

According to an embodiment, at least one service context is stored inthe device, wherein the service context comprises at least theconfiguration data set. Access to the service context is allowed for theapplication on the basis of the access control information only if theapplication is, by the external managing entity, predetermined in accesscontrol information associated with the service context. Various usagecontexts, possibly comprising also non-settings related data, such asuser related data stored by an application in the device, may then beprovided in the device.

BRIEF DESCRIPTION OF THE FIGURES

The invention is now described in greater detail by means of someembodiments and with reference to the attached drawings, in which

FIG. 1 illustrates a management system,

FIG. 2 illustrates a device with multiple configurations,

FIG. 3 illustrates a method according to an embodiment of the invention;and

FIGS. 4 a and 4 b illustrate a method according to an embodiment of theinvention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS OF THE INVENTION

One embodiment of the invention will be described in the following in asystem supporting OMA device management; it should, however, be notedthat the invention can be applied to any device management system inwhich configurations in a managed device may be managed by an externalmanagement entity.

FIG. 1 illustrates a networked system. A network server or a PCtypically serves as a server S. For instance, a mobile station, PC,laptop computer, a PDA (Personal Digital Assistant) device, or a modulethereto may serve as a terminal TE. In the following embodiments, it isassumed that for device management, the terminal TE serves as a devicemanagement client and the server S as a device management server. Theserver S can manage several clients TE.

In the first example of FIG. 1 clients TE and management servers S areconnected to a local area network LAN. A client TE connected to thenetwork LAN comprises a functionality, such as a network card andsoftware controlling data transmission, for communicating with thedevices in the network LAN. The local area network LAN can be any kindof local area network and TE can also be connected to the server Sthrough the Internet typically using a firewall FW. The terminal TE canalso be connected to the local area network LAN wirelessly through anaccess point AP.

In the second example, the client TE communicates with the server Sthrough a mobile network MNW. A terminal TE connected to the network MNWcomprises a mobile station functionality for communicating wirelesslywith the network MNW. There may also be other networks, such as a localarea network LAN, between the mobile network MNW and the server S. Themobile network MNW can be any wireless network, for instance a networksupporting GSM services, a network supporting GPRS (General Packet RadioService) services, a third-generation mobile network, such as a networkaccording to the network specifications of 3GPP (3^(rd) GenerationPartnership Project), a wireless local area network WLAN, a privatenetwork, or a combination of several networks. In addition to theexamples above, many other device management configurations are alsopossible, such as a management connection between terminals TE or adirect management connection between the terminal TE and server S byusing a wireless or a wired connection with no other network elements.

The terminal TE and the server S comprise memory, a user interface, I/Omeans for data transmission, and a central processing unit comprisingone or more processors. The memory has a non-volatile portion forstoring applications controlling the central processing unit and forother information to be stored, and a volatile portion to be used intemporary data processing.

Computer program code portions executed in the central processing unitcan cause the server S to implement the inventive means for establishingand managing service contexts in the terminal TE, some embodiments ofwhich are illustrated in connection with FIG. 4 a. Computer program codeportions executed in the central processing unit of the terminal TE cancause the terminal TE also to implement the inventive means forarranging configurations into the terminal and for arranging use ofconfigurations in the terminal TE, some embodiments of which areillustrated in connection with FIGS. 2, 3, 4 a, and 4 b. It is to benoted that one or more entities may carry out the inventive functions.For instance, some of the features illustrated in FIG. 3 are carried outby a specific access controller in the terminal TE, whereas some otherfeatures are carried out by an application in the terminal TE. Thecomputer program can be stored on any storage medium, from which it canbe loaded into the memory of the device TE; S running the computerprogram. The computer program can also be loaded through the network byusing a TCP/IP protocol stack, for instance. It is also possible to usehardware solutions or a combination of hardware and software solutionsto implement the inventive means. A chip unit or some other type ofmodule for controlling the device TE and/or S may, in one embodiment,cause the device TE and/or S to perform the inventive functions. A datastructure comprising service context specific information can betransferred over a data transmission network, for instance, from theserver S to the terminal TE and stored in the memory of the terminal TE.

In one embodiment, the terminal TE and the server S are arranged tosupport the OMA device management (DM). The terminal TE serving as anOMA device management client comprises a client agent functionality thattakes care of functions related to the management session in the client.The server S serving as a device management server comprises a serveragent or a server master functionality managing the management session.However, it is to be noted that the application of these functionalitiesis not limited to any specific devices, and it is even possible that theclient and server functionalities are implemented in a single physicaldevice. One or more management trees stored in the memory of TErepresents the manageable objects in the terminal TE. The managementtree is made up of nodes and it defines at least one management objectformed of one or more nodes or at least one parameter of a node. Thenode can be an individual parameter, a subtree or a data collection. Thenode may comprise at least one parameter that may be a configurationvalue or a file, such as a background image file in the node. Thecontents of the node can also be a link to another node. Each node canbe addressed by a uniform resource identifier (URI). An authorizeddevice management server can add (dynamic) and change contents of nodesin the management tree.

FIG. 2 illustrates a terminal TE environment 200 with multipleconfigurations. The environment 200 is provided with one or more servicecontexts 203. A service context 203 may be regarded as an area in theterminal TE to which access is controlled. Hence, information stored ina service context specific storage area in the terminal TE may specifyor form the service context 203. In one embodiment service contexts 203represent different configurations in the terminal TE used for accessingservices, for instance an Internet access service. As illustrated byarrows from the service context 203, a service context 203 representinga configuration may comprise certificates 206, settings 205, and/or someother type of data 208 specific to the service context. As illustratedin FIG. 2, information belonging to a service context 203 may be storedin multiple storage locations, or in a single storage position. Forinstance, a service context 203 may comprise or be associated withsensitive user data 208 stored in a file system 207, settings 205 andcertificates 206 stored in a central repository 204, which may be aspecific storage for service context information. Data 208 belonging toa service context 203 may be any data received in the terminal TE ororiginated by an application 202. For instance, a user may enter acalendar entry which is stored as data 208 belonging to the servicecontext 203.

A secure execution environment 201 may control access to service context203 information, and storage positions comprising service contextcontents may be secured. Although not shown in FIG. 2, the executionenvironment 201 may comprise an access controller arranged to controlaccess to service context information. An external management entity, inone embodiment of a service context manager 211, may grant rights forapplications 202 to access information belonging to a service context203. Access control information (ACI) 212 originated and/or controlledby the external management entity (211) may be stored in the terminal TEfor defining rights to access service contexts 203. Further, theexecution environment 201 may attend to securing data transfer betweenthe application 202 authorized to access the service context 203 and oneore more storage positions comprising the service context information.In one embodiment, at least some security services are arranged by anoperating system of the terminal TE.

Applications 202 may be executed inside the secure execution environment201 of the terminal environment 200. Access to one or more servicecontexts 203 is arranged for an application 202 in order to initiate aservice for a user of the terminal TE, if the access control information212 enables this. This access control information 212 may be defined inmany ways in the terminal TE. For instance, a file identifying entitiesentitled to access a service context 203 may be stored in the terminalTE, and the terminal TE is arranged to provide access to the servicecontext 203 only for entities directly or indirectly identified in thefile. The access control information 212 could be defined in terminal TEas parameters for a software component implementing service contextaccess control functions, for instance. Thus, the terminal TE isprovided with access control rules for defining entitlement to access aservice context 203. The access control information file may be a listof application identifiers or a list of application source identifiers.However, instead of or in addition to application identifiers, theaccess control information could specify access control information ofother entities in the terminal TE, such as application groups orapplication execution environments. The access control information 212may be service context or service context group specific. For instance,access control information 212 may comprise a plurality of differentprofiles for corporate access, tailored for different usage situations.In one embodiment, this administrative access control information 212belongs to the service context information.

In accordance with an embodiment, a certificate 206 of an application202 is checked in order to reliably define an identifier associated withthe application 202. On the basis of this identifier, the terminal TE isthen arranged to check whether or not the application 202 is entitled toaccess the service context 203. These certificates 206 may be storedwithin service context information (for instance the certificate 206 inthe central repository 204) and/or outside the service context 203, forinstance within application 202 data in the file system 207. Thecertificate 206 is associated with at least one application 202 in theterminal TE. The certificate 206 has been issued and digitally signed bya trusted third party, such as a general certification authority or anapplication developer, to prove the integrity and source of theassociated application 202. The certificate 206 could be obtained forthe terminal TE separately from the access control information 212, forinstance during installation of application, or it may even form a partof the service context information or access control information fromthe managing entity. It is to be noted that the certificate 206 may inone embodiment be acquired during the access control procedure forchecking the right of the application 206 to access certain servicecontext 203. The certificate 206 may include at least some of thefollowing: a name of the certificate holder, a serial number, anexpiration date, a copy of the certificate holder's public key, and thedigital signature of the issuer so that a recipient can verify that thecertificate is authentic.

As also illustrated by the broken lines in FIG. 2, the service contexts203 may be managed by the external authorized managing entity 211. Thismay mean that some or all of the information belonging to the servicecontext 203 may be read, added, modified, and/or removed by the externalmanaging entity 211. In one embodiment, the OMA DM is applied tomanaging service contexts 203. At least some of the service context 203information may be stored in a management tree, which is modified by adevice management agent on the basis of device management commands froman OMA device management server (S).

FIG. 3 illustrates a method of an embodiment for using service contextsin terminal TE. In step 301, there may be a need to initiate a serviceby an application 202 such that the application 202 requires informationstored under one or more service contexts 203 for service set-up, or forsome other purpose. This need typically arises based on a user input,but a service may also be initiated based on some other trigger, such asa command from an external device. Service contexts 203 available forthe service may be checked in step 302. If the check 302, 303 revealsmore than one available service context 203, a preferred service context203 is selected 305. For instance, the terminal TE may store apreference list indicating the service contexts 203 in a preferenceorder. A default service context 203 could be selected in step 305.Otherwise, an available service context 203 is selected 304. Theapplication 202, or an application manager, may be adapted to performsteps 301 to 305. Although not shown in FIG. 3, it is to be noted thatthe service context selection procedure may involve prompting a user ofthe terminal TE to select a service context and/or to confirm theselection of the service context.

The method then proceeds to step 306, wherein access to a selectedservice context is requested or a need to access the service contextspecific data is otherwise indicated. On the basis of access controlinformation 212 from and/or controlled by a managing entity, it ischecked 307 whether the application 202 is authorized to access theservice context 203. The relevant access control information 212 may beobtained from the memory of the TE, or in one embodiment the terminal TEmay be arranged to request and receive access control information froman external entity, such as the external managing entity 212. Themanaging entity may be the service context manager 211 or some otherentity, for instance an entity that has issued the certificate 206. Ifthe application 202 is not authorized, access for the application 202 isdenied 308 to the service context 203.

According to an embodiment, step 307 comprises two sub-steps. First, acertificate 206 associated with the application 202 requiring access tothe service context 203 is checked. By checking the certificate 206 itis possible to ensure the integrity and/or source of the application202. In a second sub-step, an identifier obtained from the application's202 certificate 206 is compared with identifiers in predetermined accesscontrol information 212. An application source identifier from thecertificate 206 may in one embodiment be compared in the second sub-stepwith predetermined application source identifiers in the access controlinformation 212. The access control information 212 in the presentembodiment specifies those applications, groups of applications orapplication sources that are authorized to use the service context 203.Thus, if the identifier from the certificate 206 of the application 202can be found in the access control information 212, the application isauthorized.

If the application 202 is authorized on the basis of a check 307, theapplication may access 309 information associated with the servicecontext 203, and the application 202 may then initiate 310 the serviceon the basis of the associated service context information.

In one embodiment, the service context 203 comprises or is associatedwith settings required for arranging a connection from the terminal TEto one or more network resources for accessing a service. Thus, theapplication 202 may in step 310 establish a connection using thesesettings. These settings could specify access to corporate intranetresources, such as an email server and an email account. However, alsomany other services exist for which the service context 203 may be used.

In an embodiment, the terminal TE comprises access controlledapplication (specific) data 208 belonging to or associated with aservice context 203 such that access to the application data 208 isarranged only for applications 202 authorized by the external managingentity 211. This application data 208 is typically user related andstored by an application 202 in the terminal TE on the basis of a userinput. In step 310 the application data 208, such as a file comprisingcorporate e-mails, may be displayed and possibly further processed by anapplication 202 (an e-mail client application in this example).

A service context 203 may be selected or defined when using anapplication 202. A service context 203 may be selected when anapplication 202 is activated and/or when new contents are to bespecified as service context information. For instance, when an e-mailapplication is activated, the user selects a desired profile or e-mailaccount, whereby a service context associated with the profile or e-mailaccount is also selected. Thus, when the application 202 later requiresaccess to service context 203 information, steps 302 to 305 areunnecessary but information in the associated service context 203 may beused, for instance for establishing a connection to a remote e-mailserver. In another embodiment, a service context 203 may be specifiedfor a user data item, such as an e-mail message. This service context203 could be selected in connection with storing of a data item. Forinstance, when the user has finished preparing an e-mail item andselects to store the item, available service contexts 203 (for thee-mail application) are shown to the user. The user may then select theservice context 203 with which the data item is to be associated andthus possibly the storage position of the data item, and the data itemis stored accordingly. Later, the data item may be used as any otherservice context 203 specific data, i.e. access to the data item isallowed only for authorized applications 202.

In one embodiment, access to the service contexts 203 is controlled(steps 307 to 309) by a security procedure in the secure executionenvironment 201, such as a specific access controller entity. It is alsofeasible that the execution environment 201 checks 303 and selects 304,305 a service context 203 for the application 202. A specific servicecontext selector may be provided in the secure execution environment201.

In another embodiment, service contexts 203 available for theapplication 202 requiring access to the service context 203 are checkedalready in step 302. In this embodiment, only service contexts 203 forwhich the certificate of the application 202 allows access (or for whichthe application has access authorization by some other means) areconsidered for the service. In this embodiment, access to a servicecontext 203 is attempted only by authorized applications 202 andunnecessary requests are thus avoided.

FIGS. 4 a and 4 b illustrate a method for establishing and/or modifyinga service context 203 in the terminal TE by the server S according to anembodiment. In FIG. 4 a, features of the server S functioning as thedevice management server are illustrated. In step 401, a need exists tocreate a new service context 203 and/or to modify an existing servicecontext 203 in the managed terminal device TE. In another embodiment, aneed exists to add or modify access control information 212 related to aservice context 203.

A device management session is then arranged 402 between the devicemanagement server functionality in the server S and the devicemanagement client functionality in the terminal TE. Conventional OMA DMsession establishment functions illustrated in the OMA specification“SyncML Device Management Protocol”, version 1.1.2, 12 Dec. 2003, 41pages, may be utilized.

Service context related information, for instance connection settings205, and/or access control information 212, are specified 403 in one ormore device management commands. In the present embodiment, at leastsome of the service context information in the device managementcommand(s) is addressed to one or more service context specific devicemanagement tree nodes. The management command is transmitted 404 to theterminal TE.

FIG. 4 b illustrates functions in the terminal TE receiving servicecontext related information. In step 410, a device management command isreceived from a device management server (S). The service contextrelated data, including access control information, may be stored in theterminal TE. More specifically, in step 411 the device management clientin the terminal TE defines the required actions on the basis of thereceived device management command. The device management tree in theterminal TE may then be modified by the new and/or modified informationrelated to the service context 203. For instance, a new node may beadded with an ACL list defining the server S as being the onlyauthorized device management server to modify the node. It is to benoted that the management tree may only serve as a view to the managedinformation, whereby the managed information may be stored outside themanagement tree.

If the service context 203 is created for the first time and devicemanagement has not been provisioned for the terminal TE, OMA clientprovisioning methods may be used first to initiate and configure thedevice management before service context specific management commands.Thus, in steps 402 and 410, a connection for arranging provisioning maybe utilized.

The management tree may comprise one or more nodes for access controlinformation 212, even if the access control information 212 is not partof the service context 203. In a manner similar to that illustratedabove, by utilizing a device management command addressed to a node foraccess control information 212, it is possible to arrange themodification, deletion, or addition of access control information 212.Thus, an external managing entity may easily change the access controlconfiguration in the managed device TE. It is to be noted that FIGS. 4 aand 4 b are only exemplary. For instance, the device management commandcould be formed before the establishment of the management session. Inone embodiment, a service context 203 may be created or modified by anauthorized party in the terminal TE, for instance a user. Similarprocedures as already illustrated in connection with FIG. 3, steps306-309 may be utilized when accessing service context information. Itis thus unnecessary to apply device management mechanisms to modifyservice context 203 information.

In one embodiment, the service context manager 211 or a serviceprovider, in the embodiment of FIG. 4 a the server S, may check that asuitable service context is in place and/or used appropriately in theterminal TE. The service provider may thus check that correct settingsare in place and only applications from a trusted source are used. Thischeck could be implemented by using OMA DM GET commands to the nodescomprising this service context data. This embodiment may be implementedafter steps 404 and 412 or at some other point of time, for instanceafter receiving a service request from an application 202 in theterminal TE.

In steps 402, 403, 410, and 411, it is possible to utilize themechanisms of the device management protocol and the messages definedfor it; for a more detailed description of the OMA device managementprotocol and other commands, for instance, reference is made to the OMAspecification “SyncML Device Management Protocol”, version 1.1.2, 12Dec. 2003, 41 pages, and the OMA specification “SyncML RepresentationProtocol Device Management Usage”, version 1.1.2, 12 Jun. 2003, 39pages.

In accordance with an embodiment, the contents of a service context 203may be associated with different access control rules and/or accessright levels on the basis of the access control information 212. In afurther embodiment, different access rules are applied to differentportions of the service context 203. For instance, settings 205 of theservice context 203 specifying a connection to a corporate email servermay be read (by an application 202 authorized to access the servicecontext 203) but not modified, whereas access to data 208 in a filesystem 207 associated with the service context 203 may be both read andmodified. In this embodiment, the contents of service contexts 203 maybe differentiated in respect of access control.

Some exemplary rules that may be applied as the above-illustratedembodiment are: right to read (all or only a specific part of theservice context data), right to remove, and right to add. The accesscontrol rules and/or right levels may be specified within the accesscontrol information 212 or some other storage. In one embodiment, accesspolicies are specified by XACML (Extensible Access Markup Language). IfOMA DM is applied, access control lists may be specified in a managementtree for determining one or more external device management serversauthorized to access associated service context related data, i.e. theexternal management entities may be specified by OMA DM access controllists.

In an alternative or complementing embodiment, different access controlrules are associated with different users of the service contexts 203 onthe basis of the access control information 212. In this embodiment, itis possible to apply different access rights for different applications202 and users of the terminal TE, for instance. As an example, a servicecontext 203 (or part thereof) may be set to be modifiable only by theuser of or the subscriber to the terminal TE and an external managingentity originating and/or controlling the service context 203.

In one embodiment, the user of or the subscriber to the terminal TE isalways entitled to remove or delete service contexts 203 from theterminal TE. Since a service context 203 is required for obtaining aservice, the terminal TE cannot be used for accessing the service afterthe service context 203 has been deleted. Thus no full control needs tobe given for any administrator 211 of a service context 203, and usersdo not have to give up a right to control their terminals. No servicecontext needs to be forced to any terminal but the user/subscriber maywish to use a service and therefore accept a service context into theterminal TE. Since the service context 203 itself may be set to bemodifiable only by the authorized management entity (211), it ispossible to prevent access of the user to modify the service context203.

In a further embodiment, a capability to inform the authorized managingentity 211 about user deleted service contexts 203 is provided. Afeature or application 203 handling deletion of a service context 203 onthe basis of a user input may be configured to transmit a message to theauthorized managing entity 211 informing about the deletion of theservice context 203 from the terminal TE. In another embodiment, theauthorized managing entity 211 is configured to check the servicecontexts 203 (which it is authorized to view) in the terminal TE inorder to detect deleted ones. For instance, periodic checks may beperformed by OMA DM procedures on the nodes comprising service contextdata.

It should be noted that the embodiments described above could also beapplied in any combination thereof. It is apparent to a person skilledin the art that while technology advances, the basic idea of theinvention can be implemented in many different ways. The invention andits embodiments are thus not restricted to the examples described above,but can vary within the scope of the claims.

The invention claimed is:
 1. A method comprising: storing multipleconfiguration data sets and a plurality of applications in a device,checking access control information for defining a right of anapplication in the device to access a configuration data set in responseto an indication from an application in the device requiring access to aconfiguration data set, and in response to the application beingentitled to access the configuration data set, on the basis of theaccess control information, arranging access to the configuration dataset for the application, wherein at least one service context is storedin the device, the service context comprising at least the configurationdata set, and access to the service context is allowed for theapplication on the basis of the access control information if theapplication is authorized on the basis of access control informationassociated with the service context, wherein access control informationcomprises at least one of information specified by an external entityand information controlled by an external entity.
 2. A method as claimedin claim 1, wherein selection of a configuration data set is arrangedfor the application in response to a plurality of configuration datasets being available for the application.
 3. A method as claimed inclaim 1, wherein a service is arranged by the application on the basisof at least part of the configuration data set.
 4. A method as claimedin claim 1, wherein at least one of the configuration data set and theaccess control information thereon is arranged into the device by:establishing a device management session or a connection for arrangingprovisioning between a device management server and the device,receiving said at least one of the configuration data set and the accesscontrol information through the device management session or theconnection for provisioning, and storing said at least one of theconfiguration data set and/or the access control information in thedevice.
 5. A method as claimed in claim 1, wherein the service contextcomprises user related data stored by an application of the device.
 6. Amethod as claimed in claim 1, wherein the configuration data setcomprises settings required for arranging a connection from the deviceto one or more network resources for accessing a service, the methodfurther comprising establishing a connection to one or more networkresources on the basis of the settings.
 7. A method as claimed in claim1, wherein data transfer between the application authorized to accessthe configuration data set and a storage position comprising theconfiguration data set is secured.
 8. A method as claimed in claim 1,wherein access to a configuration data set is controlled on the basis ofcomparison between predetermined identifiers in the access controlinformation and an identifier in a certificate associated with theapplication and certifying a source of the application.
 9. A devicemanagement system comprising a device management server and a devicemanagement client to be managed, wherein the device management system isconfigured to manage at least one device management client by means of amanagement structure comprising at least one node, the system isconfigured to store access control information originated or controlledby an external managing entity for defining a right of an application ina device comprising the device management client to access aconfiguration data set, the system is configured to check the accesscontrol information in response to an indication from an application inthe device requiring access to a configuration data set, in response tothe application being, on the basis of the access control information,entitled to access the configuration data set, the system is configuredto provide the application with access to the configuration data set,and the system is configured to arrange a service by the application onthe basis of at least part of the configuration data set.
 10. A dataprocessing device, comprising at least one memory including computerprogram code, and at least one processor, wherein the memory and thecomputer program code are configured to, with the at least oneprocessor, cause the device at least to: store multiple configurationdata sets and access control information for defining a right of anapplication in the device to access a configuration data set, check theaccess control information in response to an indication from anapplication in the device, of a plurality of applications, requiringaccess to a configuration data set, and arrange access to theconfiguration data set for the application in response to theapplication being entitled to access the configuration data set, on thebasis of the access control information, wherein the data processingdevice is caused to store at least one service context comprising atleast the configuration data set, and the data processing device iscaused to allow the application to access the service context on thebasis of the access control information if the application is authorizedon the basis of access control information associated with the servicecontext.
 11. A data processing device as claimed in claim 10, whereinthe service context comprises user related data stored by an applicationof the data processing device.
 12. A data processing device as claimedin claim 10, wherein the configuration data set comprises settingsrequired for arranging a connection from the device to one or morenetwork resources for accessing a service, and the data processingdevice is caused, by the memory and the computer program code with theat least one processor, to establish a connection to one or more networkresources on the basis of the settings.
 13. A data processing device asclaimed in claim 10, wherein the data processing device is caused, bythe memory and the computer program code with the at least oneprocessor, to arrange selection of a configuration data set for theapplication in response to a plurality of configuration data sets beingavailable for the application.
 14. A data processing device as claimedin claim 10, wherein data transfer between the application authorized toaccess the configuration data set and a storage position comprising theconfiguration data set is secured.
 15. A data processing device asclaimed in claim 10, wherein access to a configuration data set iscontrolled on the basis of comparison between predetermined identifiersin the access control information and an identifier in a certificateassociated with the application and certifying a source of theapplication.
 16. A data processing device as claimed in claim 10,wherein the data processing device comprises a device management clientaccording to an Open Mobile Alliance device management standard, and thedata processing device is caused, by the memory and the computer programcode with the at least one processor, to perform at least one of add aconfiguration data set and modify a configuration data set on the basisof a device management command received from a device management serverto a node of a management tree in the data processing device.
 17. A dataprocessing device as claimed in claim 10, wherein the data processingdevice is caused, by the memory and the computer program code with theat least one processor, to check the access control information inresponse to a request from the application to access the configurationdata set.
 18. A data processing device as claimed in claim 10, whereinthe data processing device is caused, by the memory and the computerprogram code with the at least one processor, to arrange a service bythe application, based at least in part on the configuration data set.19. A data processing device, comprising at least one processor, and atleast one memory including computer program code, wherein the at leastone memory and the computer program code are configured to, with the atleast one processor, cause the data processing device at least to:transmit management commands to a managed device, and control accesscontrol information for defining a right of an application in themanaged device to access a configuration data set in the managed device,wherein the access control information controlled by data processingdevice is associated with at least one service context of the manageddevice, the service context comprising at least the configuration dataset, and the access control information defines the right of theapplication to access the service context.
 20. A data processing deviceas claimed in claim 19, wherein the data processing device is configuredto establish a device management session with the managed device, thedata processing device is caused to form a device management commandaddressed to a node representing at least one of the access controlinformation and the configuration data set in a management tree of themanaged device, and the data processing device is caused to transmit thedevice management command to the managed device.
 21. A data processingdevice as claimed in claim 19, wherein the data processing device is adevice management server according to the Open Mobile Alliance devicemanagement standard.
 22. A data storage medium storing a computerprogram product downloadable into a memory of a data processing device,the computer program product comprising computer program code which,when executed in a processor of the data processing device, causes thedata processing device to: check access control information for defininga right of an application in the device to access a configuration dataset in response to an indication from an application in the devicerequiring access to a configuration data set, and in response to theapplication being entitled to access the configuration data set, on thebasis of the access control information, arrange for access to theconfiguration data set for the application, wherein at least one servicecontext comprising at least the configuration data set is stored in thedata processing device, and allow the application to access the servicecontext on the basis of the access control information if theapplication is authorized on the basis of access control informationassociated with the service context.
 23. A data storage medium accordingto claim 22, the computer program product comprising computer programcode for checking the access control information in response to arequest from the application to access the configuration data set.
 24. Adata storage medium as claimed in claim 22, wherein the service contextcomprises user related data stored by an application of the device. 25.A data storage medium as claimed in claim 22, wherein the configurationdata set comprises settings required for arranging a connection from thedevice to one or more network resources for accessing a service, themethod further comprising establishing a connection to one or morenetwork resources on the basis of the settings.
 26. A data storage asclaimed in claim 22, wherein the computer program product comprisingcomputer program code for arranging selection of a configuration dataset for the application in response to a plurality of configuration datasets being available for the application.
 27. An apparatus comprising: atransmitter for transmitting device management commands to a manageddevice, a controller for controlling access control information fordefining a right of an application in the managed device to access aconfiguration data set in the managed device, wherein the access controlinformation controlled by the apparatus is associated with at least oneservice context of the managed device, the service context comprising atleast the configuration data set, and the access control informationdefines the right of the application to access the service context. 28.The apparatus as claimed in claim 27, wherein the apparatus isconfigured to establish a device management session with the manageddevice, the apparatus is configured to form a device management commandaddressed to a node representing at least one of the access controlinformation and the configuration data set in a management tree of themanaged device, and the apparatus is configured to transmit the devicemanagement command to the managed device.
 29. The apparatus as claimedin claim 27, wherein the apparatus is configured to provide a devicemanagement server according to Open Mobile Alliance device managementstandard.
 30. An apparatus comprising: means for storing multipleconfiguration data sets and a plurality of applications, means forstoring access control information for defining a right of anapplication in the apparatus to access a configuration data set, meansfor checking the access control information in response to an indicationfrom an application in the apparatus requiring access to a configurationdata set, and means for arranging access to the configuration data setfor the application in response to the application being entitled toaccess the configuration data set, on the basis of the access controlinformation, wherein the apparatus is configured to store at least oneservice context comprising at least the configuration data set, and theapparatus is configured to allow the application to access the servicecontext on the basis of the access control information if theapplication is authorized on the basis of access control informationassociated with the service context.